Always remove unused Import statements
Always reformat the code using an IDE (Intellij is commonly used)
Always check an Object is not null before using it
Ensure code is broken down into methods which perform a single task
Methods are permitted to have multiple return statements if they allow for concise checking and reporting of entities.
Use Product API methods (such as GroovyApi) as much as possible
At the start and end of a Groovy class, write the date and time to the log to aid debugging
N4 Logging methods (such as "log()" for normal output or "logWarn()" for errors) are preferred to "println"
Always ensure finished production code never calls "println" as the output file will never be truncated and can eventually cause problems
Install instruction and test steps will be provided in release notes
When defining Domain Queries and using them to load entities, be careful to avoid loading every entity of a given type (potentially resource-heavy). Use predicates, set the max number of results or set an Ordering instead.
Alternately, it may be possible to load the primary keys of all matching entities (findPrimaryKeysByDomainQuery) and then loading only the required entities from the keys.
Set the package of the code (com.Navis.extension.[customer]) and use the log4j Logger, rather than the default log() methods. You can then log at different levels (error, warn, info, debug and trace) which can be configured to show or hide in the logs. This way, it is trivial to define the level of information visible in the logs with configuration in N4.
You may want to define methods in your code (such as myDebugLogMessage(String)) to handle the log4j logger for you.
Not allowed to do the coding in the General Notice:-
The worst option to write groovy code is in the general notice - Execute Code because it is very difficult to debug if any logic is written in the Notice Request form. This should be used only as the trigger location to call a code extension and not the full code.